検証: Windows Defenderに引っかかったService Workerのキャッシュを探す
{長い文字列A}はScrapboxのService Workerのパスで間違いない
キャッシュを削除→Scrapboxにアクセス→...を繰り返しても同じ
後日、別PC(Mac)のCacheStorageも確認したが同じだった
c39...
{長い文字列B}はどういうルールで生成されているのかわからなかった
ソースの中身を追えば推測できるのかな？
{長い文字列A}/index.txtを見つけた、完全な状態では開けなかったが少し推測できた(2022/03/01)
code:index.txt_イメージ
prefetch ${長い文字列B部分に該当する_1}
api-2022-02-28 ${長い文字列B部分に該当する_2}
image-2022-02-28 ${長い文字列B部分に該当する_3}
assets-20220228-070819 ${長い文字列B部分に該当する_4}
api-2022-03-01 ${長い文字列B部分に該当する_5}
image-2022-03-01 ${長い文字列B部分に該当する_6}
index.txt_イメージはどこかで見覚えがある
Scrapboxを開いた状態でDevTools > Application > Cache > Cache storageにアクセスしたときに表示されるキャッシュ群だ
code:DevTools > Application > Cache > Cache storage
DevToolsのCache storage(例えばapi-2022-02-28)で表示されるキャッシュファイル数と、{Chromeのプロファイル}\Service Worker\CacheStorage\{長い文字列A}\{長い文字列B部分に該当する_2}フォルダ直下に作られているファイル数がほぼ一致した！
以下が存在しているのが異なる点
code:ㅤ
index-dir/
the-real-index
index
これらはなにものなのか開いてもまったくわからなかった
上記の推測のおかげでわかったこと
{長い文字列B}はおそらく同じ文字列にはならない
prefetch以外のキャッシュは後ろに日付がついているので、日付が変わったら新しい文字列になるはず
{長い文字列B}/ファイルのファイルの文字列は恐らく再現する
同じファイルをキャッシュに溜めると同じ文字列で保管される/された
キャッシュだから
/api/...系のリソース
/api/code/...
/api/pages/...
/api/projects/...
など
画像
gyazoの画像
iconも含む
/assets/...系のリソース
フォント、cssなど
ただしassetsまわりだと引っかかった人がもっといそうなので、これは除外してもいいと思う
例えばどこかのプロジェクトのページ内にコードブロックで「CoinHiveのサンプル.js」みたいなソースコードがあったとして、そのソースがキャッシュに溜まるとWindows Defenderに検知される可能性がないだろうか？ この場合はapi-yyyy-mm-ddに溜まる/api/code/プロジェクト名/ページ/CoinHiveのサンプル.jsが怪しいことになる
素Windowsなのでこれ以上の詳細なログは管理者権限がないと閲覧できないためわからない… 検疫済ファイルも確認不能…
誤検知の可能性もあるが、検知しちゃった時点で「大丈夫ですか？何か踏んでませんか？」と連絡がくる
同じ状況でキャッシュにたまったら再現する可能性がある？
CacheStorageに同じファイル名が生成されたら通知するようにして再現待ち…(2022/02/25)